Release Refactoring
===================

`View article on our wiki <https://xscale.wiki/#Release%20Refactoring>`__

-  Release planning works to maximise `Product Market
   Impact <https://xscale.wiki/#Impact%20Mapping>`__ and thereby
   business `Throughput <https://xscale.wiki/#Throughput>`__ by
   reconciling feature priorities and calendar dates with quantified
   `Release Goal <https://xscale.wiki/#Release%20Goal>`__\ s across the
   `Epic Landscape <https://xscale.wiki/#Epic%20Landscape>`__.
-  Business, design and technical stakeholders self-organize into
   `Product Squad <https://xscale.wiki/#Product%20Squad>`__\ s and
   `Portfolio Council <https://xscale.wiki/#Portfolio%20Council>`__\ s
   to collaborate on tradeoffs for this purpose using `Leadership as a
   Service <https://xscale.wiki/#Leadership%20as%20a%20Service>`__ and
   `Open Book
   Management <https://xscale.wiki/#Open%20Book%20Management>`__.
-  When solution assumptions fail, market conditions change, new
   business, design or technology constraints are identified, or other
   significant learnings show up, feature priorities and release plans
   must be adapted to them immediately to maintain
   `Throughput <https://xscale.wiki/#Throughput>`__.

**Therefore,**

Release Refactoring is a rapid consensus game that enables quick numeric
trade-offs between different feature-sets while respecting calendar
dates and budget limits for a release goal.

1.  This is a game for the entire `Product
    Squad <https://xscale.wiki/#Product%20Squad>`__ - business
    stakeholders make the decisions but design and tech stakeholders
    question them and answer questions.

2.  Using the `Royal Cod <https://xscale.wiki/#Royal%20Cod>`__
    prioritization derived by `Business
    Bingo <https://xscale.wiki/#Business%20Bingo>`__, lay out all
    available `Feature <https://xscale.wiki/#Feature>`__\ s in columns
    grouped by `Epic <https://xscale.wiki/#Epic>`__.

3.  Pick the first column. Pick the feature at the top of the column.
    Let business stakeholders say whether the `Release
    Goal <https://xscale.wiki/#Release%20Goal>`__ can be satisfied for
    this Epic without including that feature. If they disagree, use
    `Leadership as a
    Service <https://xscale.wiki/#Leadership%20as%20a%20Service>`__ to
    resolve the matter.

4.  Continue down the column, feature by feature, until the business
    stakeholders agree that one of the features isn’t critical for the
    `Release Goal <https://xscale.wiki/#Release%20Goal>`__ for this
    `Epic <https://xscale.wiki/#Epic>`__.

5.  Call all the features above that one **bronze** and all the ones
    below them **silver**.

6.  Now ask the business stakeholders whether any of the silver features
    could be deferred till the following release without impacting the
    `Release Goal <https://xscale.wiki/#Release%20Goal>`__. Call the
    ones that can be deferred “gold”.

7.  Total how many feature points are in each of bronze, silver and gold
    levels for that Epic.

8.  Total how much `ROI <https://xscale.wiki/#ROI>`__ are in each of
    bronze, silver and gold levels for that Epic.

9.  Repeat the above steps for all columns.

10. If you’re working to create a release plan for a particular date,
    determine how many feature points correspond to that constraint. Now
    simply select the combination of bronze, silver and gold groups with
    the maximum `ROI <https://xscale.wiki/#ROI>`__ within that number.

11. Let stakeholders do some fine tuning and trade-offs of features from
    different epics to respect `COD <https://xscale.wiki/#COD>`__
    issues. But make certain they start with the bronze/silver/gold
    tranches so keep this conversation manageable.

12. If fitting to a continuous delivery funding model rather than a
    specific date, use `Getting Features
    Done <https://xscale.wiki/#Getting%20Features%20Done>`__ instead.

13. Keep the refactoring board on an `Information
    Radiator <https://xscale.wiki/#Information%20Radiator>`__ to assure
    continuous alignment of authorities and for context for the next
    `Release Refactoring <https://xscale.wiki/#Release%20Refactoring>`__
    session.

Release Refactoring is played whenever new features are added to the
`Acceptance Matrix <https://xscale.wiki/#Acceptance%20Matrix>`__,
whenever `Sprint Planning <https://xscale.wiki/#Sprint%20Planning>`__
indicates a feature’s budget is blown, or whenever the PO calls for it.
Because this is such a quick game it’s also possible to play using
set-based `Simple Design <https://xscale.wiki/#Simple%20Design>`__ in an
`R&D Stream <https://xscale.wiki/#R&D%20Stream>`__ mode to evaluate
alternative product plans to evaluate possible responses to changes in
market conditions.